Internet traffic is typically handled by default in accordance with a so-called Best Effort (BE) policy. This has not been a problem with traditional data applications such as Hyper Text Transfer Protocol (HTTP), File Transfer Protocol (FTP) and Network Virtual Terminal Protocol (TELNET), as these applications do not place limits on traffic delay and jitter, although a long wait for an HTTP get request or an FTP download would annoy a user. However, many real-time applications require better QoS assurances than the default BE to allow them to perform as required. Voice over Internet Protocol (VoIP) is a good example of traffic that must be protected as it traverses the Internet. Resource Reservation Protocol (RSVP) is a protocol that allows the QoS needs of real-time applications to be signaled to network nodes that are traversed from the sender to the receiver. RSVP is described in greater detail in, for example, RSVP Version 1 Functional Specification, Internet Engineering Task Force (IETF) Network Working Group, Request for Comments (RFC) 2205, September 1997, which is incorporated by reference herein. RSVP establishes a reservation state known as soft-state in the network nodes. The sender sends RSVP PATH messages to the receiver and if the request is acceptable, the receiver responds with the soft-state reservation request back to the sender.
The need to send RSVP messages from sender to receiver and back again results in latency in the establishment of QoS. Latency associated with call setup and the establishment of QoS is unavoidable, but should also be minimized whenever possible. Other protocols, such as Session Initiation Protocol (SIP) and ITU H.323, also have an associated call setup latency in terms of a round trip time for establishing the call. In a fast or gigabit Ethernet network this latency is small, but on larger networks containing Wide Area Network (WAN) links this latency can increase significantly. Coupling of QoS signaling to call setup signaling therefore increases call setup latency. More specifically, the round trip times associated with SIP or H.323 added to the round trip time for RSVP QoS reservation unduly increases overall call setup time.
The coupling of call setup with QoS signaling also complicates the call setup mechanism. It is generally necessary to interrupt the call setup at a suitable point to perform the QoS signaling, after which call setup is resumed. Prior to resuming call setup the RSVP QoS setup status must be examined. If the status indicates QoS setup success, call setup should simply complete, but if the status indicates QoS setup failure, then the call setup must terminate gracefully. This may require feeding the error condition back to a call controller, or other similar call processing element of the system, that must then initiate a suitable action. The action could be to terminate the call setup through releasing the call and playing a tone indicative of the QoS failure. Alternatively the call setup may be terminated and the call directed over a different route. Due to the additional failure conditions that RSVP signaling brings, the complexity of the entire call setup mechanism is increased. Therefore, a need exists for a technique which reduces the dependence of QoS signaling on call setup signaling.